[Aldor-l] Compiling setup

[Christian Aistleitner]

Hello,

On Sat, 12 Aug 2006 15:24:08 +0200, Gabriel Dos Reis  
<gdr at integrable-solutions.net> wrote:

> | True is: gcc changed its behaviour in this part.
>
> GCC enforced the standard definition of C, and gave warning telling
> people they were relying on undefined behaviour.

Yes. And indeed I like the way gcc handles the issue. No doubt about that.  
Nevertheless:

True is: gcc changed its behaviour in this part.

> | Faulty user source code:
[...]
> | However, you where trying to tell me, it is not an issue of the source
> | code and thereby did not consider
> |    local a:String = "abc";
> |    a.3 := char "X";
> | bad style.
>
> *If* the declaration of a above is valid and makes 'a' a modifiable
>  string, *then* the program is correct and *should function correctly*.
> There is no "bad style" excuse to invoke.  If the proram cannot work
> correctly, then either the language is defective or the compiler is
> buggy -- FWIW, I conisder the runtime system part of the compiler.

Define what you mean by "valid".
We do not have a grammar of the Aldor language used by the current Aldor  
compiler. So it's hard to discuss validity ...
To me it is valid, as the compiler swallows it and produces working code  
with old enough gccs.


> | Assume,
> |    local a: String = "abc"
> | is considered bad style and
> |    local a: String = copy "abc"
> | is considered good style, then the whole problem *is* a style problem.
>
> I am sorry to strongly disagree.  This is not theology.  You can't
> define a programming language semantics in terms of "bad style".

Never heard a preacher talking about bad style ;)

> Either a construct is well-defined and have a meaning, or it does not.

I assume it is well-defined from the compiler point of view.
a of type String is assigned the value of applying string$String to the  
literal "abc".
No syntax problems.
No *compiler* semantics problem.
It also has a well defined meaning for the compiler.

> What is "bad" varies from people to people.
> I, for one, consider the verbose
>
>     local a: String = copy "abc"
>
> very silly, but correct.  It is probably the only way to write it to
> have a correct program, behaving correctly because the only known Aldor
> compiler fails to do its job.

No! You fail to have the correct tools at hand. If you have a too new gcc,  
you do not meet Aldor's criteria.
When working with bleeding edge software, you are often in the situation  
that some of your libraries are too new to work with other tools.
However, typically things get sorted out over time as new versions go  
mainstream.
For Aldor the problem is known for *some* time and it is still not solved.
However, if Aldor tells you "your compiler is too new" it is you not  
meeting their requirements.

> | And it is valid to declare things to be bad style. Even gcc treats the
> | problem the same way in C:
> |
> | #include <stdio.h>
> | int main( int argc, char *argv[] )
> | {
> |    char * str = "abcdefghij";
> |    str[ 4 ] = 'X';
> |    return 0;
> | }
>
> That is comparing orange and apple.  The above program is
> *explicitly ruled by the C definition* as invoking undefined
> beahviour.  First, you would have to say whether the Aldor program you
> presented has a well-defined semantics of not.  You can't hide behing
> "bad style", I'm sorry to say.

I am not comparing apples and oranges.
The C program defines this behaviour to be undefined.
The string$String functions behaviour is not defined.
This gives an undefined behaviour in both cases.

However, the semantics of the Aldor program is well defined from the  
compiler point of view, as described above. From the library point of view  
it is not.
So it might be, it is not a compiler problem, but a library problem.

And I do not consider it to be wrong to use functions that work but are  
not documented well enough. However, I might consider it bad style to use  
them.

> | > "a" above is not a constant -- or else the language could have
> | > forbidden its modification.
> |
> | Refer to §5.2 AUG. It is a constant.
>
> Back to my question: Is the program you presented correct or not?
> Here, I mean correct accordinig to the Aldor programming language.

According to the Aldor programming language (which is not entangled with  
the library Aldor), I am very sure, it is valid.

> | Yes. But you completely omit the domain String. From my point of view
> |    local litA: Literal := "abcdefghij";
> |    local strA: String  := "abcdefghij";
> | should be translated to
> |    char * litA = "abcdefghij";
> |    char strA[] = "abcdefghij";
> | or _something equivalent_ (as things get more complicated).
>
> We are in violent agreement there.

Good thing.

> The failure is translated String
> properly is the cause of the error.

And the agreement ends here :(
I do not think, the String translation is wrong, but the initialization.
I'll probably have to step down a bit to show you why. Down to the more  
gory parts of Aldor -- it's C translation.
(hopefully you noted the "something equivalent" in my previous mail)  
because that is very important.
Did you actually ever try to read the C code generated from Aldor?
Aldor does not care about what domain is represented in C code. (Mostly)  
everything is represented by FiWord -- which is unsigned long int. These  
FiWords are used as pointers to the data structures of interest.
(You might mock about lacking type information and improper use of  
"unsigned long int", but that's not important right now -- Besides I would  
join you if you camplain about it.)
Strings are represented by FiWord as well. So defining a variable to be of  
type String, gives you a FiWord -- So no specification of whether char *  
or char ..[] is meant. The Literal "abcdefghij" is passed as (FiWord)  
"abcdefghij" to the string$String function. So the string$String function  
cannot control whether or not the Literal is in read-only memory or not.
However, it is supposed to return a character sequence in read-write  
memory. (Note the "supposed", as the semantics of the stirng$String  
function, mapping a Literal to a String, is not defined). Hence it must  
_not_ simply return the (FiWord) "abcdefghij" but has to assure, it uses  
read-write memory.

>  Not that -fwritable-strings has
> disappears.

Still "removing the -fwritable-strings" triggered the problem.
Nevertheless I strongly agree, that Aldor should never have relied on  
gcc's behaviour, as it is undefined. I defended this position against  
Aldor compiler people some time ago. So we are both on the same side.

> | > aldor.conf is a workaround about an erroneous translation.  It has
> | > proven to be quite fragile and non-scalable.
> |
> | Well ... no. "-fwritable-stirngs" makes the life of library developers
> | easier. And the library (possible) more performant (no superfluous  
> copying
> | of strings) but (possible) more insecure (more writable data sections).
> | So it may even have been a design decision to use this behaviour.
>
> How good is a quick but wrong translation.

I fully agree. But I am not in charge of the language.
I never claimed, that I like the generated code...
The only thing I claimed is, that you oversimplified the problem and that  
I do not think the compiler is the main problem.

> GCC is widely used and has become quite a "standard" C compiler, used
> to compile quite a large base or source programs.  The flag went away
> a long time ago; I have not seen a complaint that it should be
> resurected.

IIRC I read some complaints, back when it has been decided, that  
writable-strings is not the way to go. These things mostly occur in legacy  
code...
But the problem should have been dealt with years ago. No doubt.
But whining about these issues helps no one. The Aldor people agree that  
there is a problem with current gccs. And they are working on making  
things work for current gcc for some months now (at least some months ago,  
a compiler developer told me, he's working on it).

We should help them to track the problem down and fix it.

--
Kind regards,
Christian