Determine the size of malloc

[James Harris]

Since ANSI C doesn't define (f)ggets, if you use it, and you don't define
it yourself, your C code isn't ANSI-compatible. There's no way to use non-
standard library functions and keep your code standard. It doesn't make
sense, and I hope it isn't what you meant. If you meant something else,
would you please clarify? I would take a guess, but I can think of at
least two different possibilities with different answers.

Well, the function itself is ANSI compatible (I think) so it's just a
question of how to include it in a given piece of code. What I meant
was how to include it. Frankly, I would generally champion
compatibility so bundling anything in stdio.h kind of goes against the
grain. Is there no better way to include the routine???

 

[Keith Thompson]

Is it not valid to want to write (and be error checked) as ANSI-
compatible C but also use (f)ggets? If so is there a way to combine
the two?

The best way to do that would have been to put the declarations of
(f)ggets into a separate header file, such as the ggets.h file that
CBFalconer actually provides as part of the distribution.

Even if you're using lcc-win, you can compile and use your own copy of
(f)ggets (it's open source and public domain), ignoring the optional
declarations in lcc-win's <stdio.h>. But you might run into some
difficulties if you want to use lcc-win *without* the "-ansic" option.
It should be possible to use your own (f)ggets in "-ansic" mode, or
the lcc-win-provided version without "-ansic".

I haven't tried this, since I don't have lcc-win myself, so I could
easily be missing something. More detailed questions about lcc-win
should probably be sent to jacob directly or posted to
comp.compilers.lcc.

 

[Harald van Dijk]

Well, the function itself is ANSI compatible (I think) so it's just a
question of how to include it in a given piece of code. What I meant was
how to include it. Frankly, I would generally champion compatibility so
bundling anything in stdio.h kind of goes against the grain. Is there no
better way to include the routine???

In that case, you can include the code of (f)ggets in your own project,
compile it with the rest of your project, putting the function
declarations in custom header files, just like you would with any other
function. This is sure to work on any conforming compiler (lcc-win32 in
conforming mode included, even though it also offers other ways to use the
functions), and makes the fact that the functions are bundled with any
implementation of the library irrelevant, because the code of (f)ggets
becomes part of your own program. If the claim that the implementation of
the functions is in the public domain is correct (I haven't checked),
there is nothing you can't do with the functions this way, legally or
technically, that you could do by relying on lcc-win32's extended library.

 

[Flash Gordon]

James Harris wrote, On 26/05/08 19:16:

Thanks for the positive feedback. Do you think it's possible to
jointly come up with a solution? It is a bit beyond a normal FAQ entry
but is similar to a FAQ issue in that the same problem is likely to
come up from time to time.

Does it really need to be in the standard library?

Malcolm said *a* standard library, not *the* standard library. There are
many standards, not just C.

AFAICT it's not
easy to add libraries to C (e.g. only <...> and "..." include options)
but how about these options:

1) .c and .h to put into the same directory as the caller,
2) code to copy verbatim into the current source file.

Is there a better option? Either way I suspect only a few lines of
code would be needed.

Personally I would say you should only rarely use 2. However, you should
seriously consider rapping up code you are likely to reuse a lot in
library(s) which you can just link to (and call up headers from) when
appropriate. Depending on your target system there are various ways to
handle this.

 

[James Harris]

In that case, you can include the code of (f)ggets in your own project,
compile it with the rest of your project, putting the function
declarations in custom header files, just like you would with any other
function. This is sure to work on any conforming compiler (lcc-win32 in
conforming mode included, even though it also offers other ways to use the
functions), and makes the fact that the functions are bundled with any
implementation of the library irrelevant, because the code of (f)ggets
becomes part of your own program. If the claim that the implementation of
the functions is in the public domain is correct (I haven't checked),
there is nothing you can't do with the functions this way, legally or
technically, that you could do by relying on lcc-win32's extended library.

Understood. Since Chuck Falconer has published his code I guess it
would have been handy if C allowed something like

#include net.att.home.cbfalconer.ggets

... but that's another issue.

 

[Antoninus Twink]

With "gcc -W -Wall -ansi -pedantic" we can expect
implicit declaration warnings for isatty and fileno.
However the result should link correctly.

Why on earth don't you include the proper headers?
#include <stdio.h>

return ((fp != NULL) && isatty(fileno(fp)));

This is horrible. Never let a frustrated Perl hacker write C.

} /* akeyboard */

Double yuck.

 

[James Harris]

James Harris wrote:

... snip ...




Standard C does. Try "#include ggets.h".

Not quite - at least not what I had in mind. The #include I was
postulating would

1) disambiguate your package from any other
2) bring in 'header' and object code
3) either load your code from the internet or select from a library
predownloaded by the site admins. The latter option to permit only
approved code to be used at a site.

--

 

[James Harris]

BTW is there a way of telling if stdin is 'connected' to a keyboard, or is
an actual file? My code sometimes has to re-read a long line and this
doesn't work well with keyboard entry.

I'd strongly recommend writing a line input function and buffering the
input so that it does work equally well with keyboard and with file
input. Remember, generality is a good goal to have in programming.

 

[James Harris]

....

Just download the ggets.c package, compile it, and then #include
that ggets.h file and the resultant object (.o, .obj, .whatever) in
your compilation run. The package (in standard C) is available at:

<http://cbfalconer.home.att.net/download/ggets.zip>

So I guess my point is why is this not done in lcc? I may be out of
step with everyone else here but this seems to me a far better
solution than including fggets in stdio.h and the standard lib. Surely
this one solution would do whether one is writing Std C or lcc C and
one straightforward solution seems better than having two ways to get
the same function.

--

 

[jacob navia]

...


So I guess my point is why is this not done in lcc?

Bezcause this supposes that

1) You are aware of the existence of ggets and its corresponding URL.
2) You are willing to download that stuff, put it somewhere and
never forget to reinstall it when your machine changes.

I may be out of
step with everyone else here but this seems to me a far better
solution than including fggets in stdio.h and the standard lib.

No. Why can't it be included in the standard lib?
It is much easier for everyone.

 

[James Harris]

Bezcause this supposes that

1) You are aware of the existence of ggets and its corresponding URL.
2) You are willing to download that stuff, put it somewhere and
never forget to reinstall it when your machine changes.

I meant, could fggets not be provided with lcc (or any other compiler
- this is not a criticism of lcc per se) in the form that CBF
distributes it? So the user would #include <ggets.h> rather than

No. Why can't it be included in the standard lib?
It is much easier for everyone.

Is it easier? I may be wrong about how this works but as I understand
it if the programmer wants ansi compilation he needs to #include
<ggets.h> or more likley "ggets.h". If he wants non-ansi he includes
<stdio.h>. Wouldn't it be easier if all code worked the same way by
including <ggets.h> in either case? Perhaps this cannot be done for
some technical reason which is really my query. Maybe it could not be
linked?

 

[Keith Thompson]

James Harris wrote: [...]

I may be out of
step with everyone else here but this seems to me a far better
solution than including fggets in stdio.h and the standard lib.

No. Why can't it be included in the standard lib?
It is much easier for everyone.

It can be, within certain restrictions, but I disagree that it's
"easier for everyone".

Specifically, adding the declarations of the fggets() function and the
ggets() macro to <stdio.h> is perfectly legal, as long as those
declarations become invisible when the compiler is invoked in
conforming mode (as they are in lcc-win). Of course, this is
vacuously true; a non-conforming implementation (which includes a
compiler invoked in a non-conforming mode) obviously has no
restrictions whatsoever placed on it by the standard.

*However*, this approach has the disadvantage that I can't easily use
fggets or ggets in a program that I want to be standard-conforming. I
can *either* have the compiler warn me about non-standard code, *or* I
ca use fggets and ggets; I can't easily do both (if I'm using lcc-win).

On the other hand, if lcc-win had provided fggets and ggets by
declaring them in their own separate header, "ggets.h", then I could
invoke lcc-win in conforming mode *and* use fggets and ggets, simply
by adding ``#include <ggets.h>'', or perhaps ``#include "ggets.h"''.

I really don't see how shoving non-standard content into a standard
header is of any help to anyone (beyond perhaps saving a few
keystrokes).

 

[jacob navia]

James Harris said:



You seem to be suggesting that this would be desirable, which should not be
taken as given.

And you seem to suggest that your opinion is something important,
what should not taken as given.

 

[Joachim Schmitz]

Why on earth don't you include the proper headers?
#include <stdio.h>
#include <unistd.h>

Because it won't allow for -ansi -pedantic

This is horrible.

Why?

Bye, Jojo

 

[Richard Bos]

Because it won't allow for -ansi -pedantic

Well? You're _not_ compiling ISO C code. You're compiling POSIX code. If
that's what you want to do, that's fine, but be up-front about it.

Why?

Because Twink is a troll who can't read idiomatic code.

Richard

 

[Joachim Schmitz]

Well? You're _not_ compiling ISO C code. You're compiling POSIX code.
If that's what you want to do, that's fine, but be up-front about it.

Which CBF is in his comments to that code:

/* This is very likely to be non-portable ....
/* This dirty operation allows gcc -ansi -pedantic */

How much more up-front could it be?

Bye, Jojo

 

[James Harris]

James Harris said:



You seem to be suggesting that this would be desirable, which should not be
taken as given.

Which bit do you take exception to? The use of ggets per se or my
query about whether it's better for non-standard headers to reside in
their own header files rather than being included within a standard
header?

 

[James Harris]

And you seem to suggest that your opinion is something important,
what should not taken as given.

I don't see that opinion comes into it (mine or RH's - not sure whom
you were targeting). I was asking for information and challenging a
viewpoint. This is permitted on Usenet, you know.

I'll set out what I understand so far to allow it to be pilloried and
otherwise corrected. Asbestos clothes on....

1) The header for a given function /can/ be provided by a compiler
package as a separate header file rather than being included inside
one of the "standard" header files.
2) Even with a separate header file it is still possible to both
compile and link (presumably bringing in the relevant object code at a
certain point).
3) C compilers can be ansi-compatible - "conforming" (term?) - or not
(non-conforming).
4) lcc includes the header of a non-ansi-standard function (ggets in
this case) in stdio.h to make things "easier for everyone."

/If/ the above is right (a big 'if' I know) I don't really see how
adding the header for ggets() to stdio.h makes things easier except
that is saves the user typing

#include <ggets.h>

at the top of a piece of code. Offset against this extra typing is
that the extra include makes it more transparent where the ggets()
header is defined. This seems to me (yes, my opinion if you like) on
its own to directly outweigh the 'disadvantage' of the extra typing.
However, that's a side point. The main query is whether a community-
provided function can be distributed such that the above #include
would be valid whether telling the compiler to use ansi compatibility
or not.

 

[Richard Bos]

Which CBF is in his comments to that code:

How much more up-front could it be?

You could #include the proper headers. This trick is, as the comment
says, dirty. And it's not as if it's going to work anywhere you don't
have those headers.

Richard

 

[James Harris]

....

The problem with trying to add the expanding buffer to the standard library
is that it depends upon malloc(), which nothing except, obviously, free(),
calloc() and realloc() depends upon, so we need a policy change.

It is also less easy than it seems to define an interface. The basic struct
members are obvious enough, but should they be visible or opaque? If we use
a void * for the buffer, how is the user going to access the contents
neatly? Should be provide bells and whistles so that the user can fine-tune
the allocation strategy?

Even a very basic question of whether the intialising function should return
an allocated struct buffer *, or should take an empty buffer * as a
parameter and fill it out, isn't obvious.

However all of the functions should be fairly straightforwards. In C++ they
would probably fit comfortably into a header. I'd go for option 1).

These seem like good questions. I'm not sure I understand them all but
to make the discussion more concrete will put up a code offering for
an expanding buffer as a separate thread and see what comes back.