Re: bison-20001221

[Hans Aberg]

At 11:40 +0100 1-01-22, Akim Demaille wrote:
>> -- The idea is of course to make something like obstack working
>> on memory, but wrapped up to look like a FILE struct. It would
>> have been easy in C++, in C I do not know.
>
>Aah, that.  Well, again, this is out of the scope of this list.  And
>indeed the Glibc has that feature:
...
>   Here is a sample function that uses `open_obstack_stream':
>
>     char *
>     make_message_string (const char *a, int b)
>     {
>       FILE *stream = open_obstack_stream (&message_obstack);
>       output_task (stream);
>       fprintf (stream, ": ");
>       fprintf (stream, a, b);
>       fprintf (stream, "\n");
>       fclose (stream);
>       obstack_1grow (&message_obstack, 0);
>       return obstack_finish (&message_obstack);
>     }

The only point with it is that it is a simpler interface than obstack
itself, so it is easier to modify. (I got the idea while writing the sorted
table patch.)

Obstack compiled just fine, I recall, and you have already written the
stuff for obstack for now, so there is no point in any immediate change.
(If I have time, I may look into your references later.)

>but it's not portable.

In order to make it portable, you would have to include the sources as
well. My linker works that if names are duplicated in both a library and a
source, then the source name is chosen. This is a convenient method for
fixing library "bugs". Does the GCC linker work the same way?

>> The header <size_t.h> is included from <stddef.h> on my
>> computer, and the latter is ISO/ANSI C.
>
>why did this size_t.h stuff show up actually?
>OK with stddefs.h etc, but this is definitely the first time I hear
>about size_t.h.

Different compilers may put their definitions in headers named as they
please. Then, in order to comply with various standards, one makes an
additional set of headers, which includes the other headers with the
original definitions.

Now, on my computer, I can find out where a name is defined by merely
clicking on it; I then (I figure, because I do not remember it anymore) got
the file size_t.h popped open.

What I should have done (in addition or instead), is to look up in the C
standard what the right header name for size_t is

>  But really, *end of this story*, I am *not*
>interested in porting Bison to MacOS.

Neither am I. :-)

Just stick to the standard C headers, whenever possible.

The ambitious way to program is to have a book or C-standard handy, and to
look up the headers filenames where the names are declared.

The next to ambitious approach is to look it up when people start
complaining :-)

>GNU is about POSIX.

It seems that one expects Bison will run on non-POSIX as well, in view that
people compile is for MSOS.

What exactly is POSIX? -- I thought it was about defining multi-threading
and such, and not an operating system in itself. The various non-C-standard
headers we are discussing here seems to be in part related to which
compiler one is using and in part which OS (like BSD etc.). Why should
POSIX bother about which header size_t is defined in?

  Hans Aberg
                  * Email: Hans Aberg <mailto:address@hidden>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>