Re: [Tack-devel] Update on porting effort

[Carl E. C. <cec...@ya...>]

Greetings,
                   I am trying to be careful on the ansification process 
so i don't break anything, so I am carefully reviewing my changes before 
doing a commit in my branch, I have some questions, because i am 
probably missing some understanding.

* Why is the alloc library relying on the system library in NoMem(void) 
? Can we simply not call fprintf(stderr.. ) and exit(EXIT_FAILURE) 
instead? It would make it more portable and less interdependent of other 
libraries, no?
* Why is the print library relying on the system library for its I/O, 
same question as before, we could just replace File* by standard FILE* ?

The only reasons i could foresee are
*  that this was done before ISO C90 and was not portable at the time?
*  when printing you may want to actually write somewhere else by 
implementing your own sys_xxx function.
*  any others?

What is the objective of the system library?
I thought it would contain API calls that are not fully portable, for 
example POSIX API's that we should "emulate" for each platform, or ISO C 
routines that must be overriden because of broken implementations in 
some libraries (tmpfile() and tmpnam() in Visual C++ come to mind)? 
other examples:
* get file modification time.
* create temp file
But I see sys_write and sys_open ... I am ok to keep them, but it should 
not be a FILE* instead?
Should it also not also add some common API's gettmpdir() that could are 
used in different utilities, maybe instead it needs to be reimplemented?

Sorry for all those questions, but it is very difficult for me to 
understand the spirit of the above...

Thanks in advance,
Carl








On 2019-02-08 00:57, Carl Eric Codere via Tack-devel wrote:
> On 2019-02-07 07:37, David Given wrote:
>> Thanks very much --- that all sounds great!
>>
>> Please, though, send lots of small PRs as you go rather than one big 
>> one. It's vastly easier to review and reduces the risk of stuff 
>> you're doing crossing stuff I'm doing. For example, I recently 
>> ANSIfied the Pascal and Basic compiler myself (although pretty 
>> crudely, just to make the warnings go away).
>>
>> [...]
> Ohoh.. you did those already? Ok, i will double check your changes and 
> try to merge them with mine. While ansifying i try to follow the 
> guidelines of the university of Michigan on C include files. Hope this 
> is ok  (umich.edu/~eecs381/handouts/CHeaderFileGuidelines.pdf).
>
> I will try to push something soon, maybe by small batches...
>>
>>     ** Move the docs to the header file when they exist in the function
>>     definition.
>>
>>
>> ...for anything other than public functions (i.e. stuff in public 
>> headers in modules/), it's best left next to the definition. This is 
>> because these usually describe the /implementation/, not the 
>> specification.
>>
>>     ** One-line sentence overview of function when I can do it.
>>
>>
>> Very valuable.
>>
>>     * Adapt to have internal prototypes and add STATIC to functions used
>>     internally to a module.
>>
>>
>> Any reason not to simply use 'static'?
> Actually you are right, but it is quite messy here, i saw that for the 
> ANSI C compiler on LINT code they used a PRIVATE define while in 
> pascal it was a STATIC define, better directly stick with the static 
> as you proposed everywhere right?
>
>>     * Add CMake and use cmake to build portable scripts:
>>     ** Create sed scripts so no more shell requirement
>>     ** Create awk scripts so no more shell requirement.
>>
>>
>> I don't think CMake will cut it with the ACK --- it's too complex. In 
>> particular, the ACK needs the same module to be compiled multiple 
>> times with different settings, and I've found very few build systems 
>> that can handle that. (I so, so badly want to use bazel for this.)
> Actually, up to now i have had no issue.... BUT you are right, that I 
> might get stuck when I am at building ACK... i will probably see what 
> can be done, but my objective was to remove all references to bash 
> shell scripts... and replace them with basic POSIX compliant tools...
>
>>     I have only ported the pascal and basic compilers now and since
>>     ack is
>>     not compiled, I am testing by hand, but i see some issues:
>>
>>
>> There is a test suite, which is run automatically by the main build 
>> system. It's not a terribly complete test suite, but it does exist.
>>
>>     * The pascal compiler generates a  PRO pseudoinstruction without the
>>     size, since its only 1 pass, so the old code generator chokes,
>>     because
>>     it expects it, I have questions on this: 
>>
>>     ** Do other compilers do this also? Will ncg also choke if the
>>     PRO does
>>     not have the locals parameters?
>>
>>
>> The compiler output is always run through em_opt before being passed 
>> to a code generator, which among other things will add the parameter 
>> to PRO. You don't need to worry about it being missing in the code 
>> generator.
> Ahhh.. ok, then after I have finished compiling the ANSI C compiler, i 
> will go with porting that so i can test a bit and then start doing 
> some pull requests... Thanks, that clarifies a lot.
>>
>>     BTW: Regarding the em documentation, I would like to update it (I
>>     see
>>     mistakes in the specification), just wondering should it be
>>     converted to
>>     something else than troff, or ok like that? Latex? Asciidoc?
>>     etc...  I
>>     will not change anything on the format for now... just want an
>>     opinion
>>     on this.
>>
>>
>> I'd very much like to keep the existing documentation, even though 
>> it's a mess. In my experience it's been surprisingly accurate; what 
>> errors did you find? Also, bear in mind that the code generators are 
>> significantly more relaxed about things like alignment than the spec 
>> actually decrees; I had to do a lot of fixing before the int 
>> interpreter would run some of the compiler output...
>>
> Agreed, i can keep troff, just need to brush up on it i guess. 
> Actually its not big mistake, more an omission, in the EM report, i 
> could not find at least in what i read how a single byte value is 
> encoded, maybe i missed it? And in the EM PDF i have, the annex gives 
> information on em encodings which do not seem to fit with what is 
> actually encoded in compact form... unless its something different?
>
> Carl
>
>
>
>
>
> _______________________________________________
> Tack-devel mailing list
> Tac...@li...
> https://lists.sourceforge.net/lists/listinfo/tack-devel