Determine the size of malloc

[Keith Thompson]

jacob navia wrote: [...]

Chuck falconer 'ggets' is distributed with lcc-win.

I suppose I'm overlooking something but won't there be license
incompatibility between Chuck's ggets and your lcc-win?

There is no license. According to the readme.txt file from ggets.zip:

I have put this in the public domain. Use as you will. I would
appreciate attribution when used.

 

[jacob navia]

Okay. In which case I think jacob must distribute a copy of ggets
license along with his own license in the lcc-win distribution.

Strangely though I can't seem to find ggets anywhere in my lcc-win
installation. Perhaps jacob has modified the source file name?

If you
#include <stdio.h>
you will find

int fggets(char* *ln, FILE *f);
#define ggets(ln) fggets(ln, stdin)

No special library is required. It is in the standard
libc.

 

[santosh]

jacob navia wrote: [...]

Chuck falconer 'ggets' is distributed with lcc-win.

I suppose I'm overlooking something but won't there be license
incompatibility between Chuck's ggets and your lcc-win?

There is no license. According to the readme.txt file from ggets.zip:

I have put this in the public domain. Use as you will. I would
appreciate attribution when used.

Oh sorry for all the confusion then. I was under the idea that ggets was
released under the GPL.

 

[jacob navia]

I suppose I'm overlooking something but won't there be license
incompatibility between Chuck's ggets and your lcc-win?

Who cares?
Neither Mr Falconer, since I have told him about it, nor me, nor the
users.

Why try to find problems where there aren't any?

But in retrospect, I should have included ggets source into the
distribution. I did that now.

 

[Keith Thompson]

If you
#include <stdio.h>
you will find

int fggets(char* *ln, FILE *f);
#define ggets(ln) fggets(ln, stdin)

No special library is required. It is in the standard
libc.

Why did you put the declaration in <stdio.h>? Are the declaration of
fggets and the macro definition of ggets inhibited when the compiler
is invoked in conforming mode? Is the following strictly conforming
program accepted?

#include <stdio.h>

void fggets(void)
{
}

int ggets(x)
{
return x - 1;
}

int main(void)
{
return ggets(1);
}

 

[jacob navia]

Why did you put the declaration in <stdio.h>? Are the declaration of
fggets and the macro definition of ggets inhibited when the compiler
is invoked in conforming mode? Is the following strictly conforming
program accepted?

#include <stdio.h>

void fggets(void)
{
}

int ggets(x)
{
return x - 1;
}

int main(void)
{
return ggets(1);
}

lcc -ansic tggets.c
Warning tggets.c: 14 Missing prototype for 'ggets'
0 errors, 1 warning
lcc tggets.c
Error tggets.c: 4 redefinition of 'fggets'
Error c:\lcc\include\stdio.h: 188 Previous definition of 'fggets' here

OK?

 

[Keith Thompson]

lcc -ansic tggets.c
Warning tggets.c: 14 Missing prototype for 'ggets'
0 errors, 1 warning
lcc tggets.c
Error tggets.c: 4 redefinition of 'fggets'
Error c:\lcc\include\stdio.h: 188 Previous definition of 'fggets' here

OK?

If "lcc -ansic" is not intended to be a conforming C implementation,
then it's perfectly ok (and I suggest that discussion of it should be
limited to comp.compilers.lcc).

If it is intended to be a conforming C implementation, then this is a
bug, and you just might want to consider fixing it.

Since I'm not an lcc-win user, I'm mostly indifferent to whether you
consider this a bug or not. But *if* you want to claim that lcc-win
(mostly) conforms to the C99 standard, my advice is to go through the
standard headers and make sure that any identifiers outside the
implementation name space that aren't specified in the standard do not
appear in conforming mode.

If I were in a position to want to use lcc-win, this kind of thing (of
which numerous instances have shown up in discussions here) would
strongly influence my decision. Your apparent attitude that it's
perfectly acceptable to add whatever declarations you like to the
standard headers is one that I find troubling. You needn't care
whether I want to use lcc-win, but you might want to care about other
users, and about conformance to the standard that you've repeatedly
advocated here.

If nothing else, consider a user who wants to compile a program that
includes its own copy of CBFalconer's ggets.

 

[Harald van Dijk]

If "lcc -ansic" is not intended to be a conforming C implementation,
then it's perfectly ok (and I suggest that discussion of it should be
limited to comp.compilers.lcc).

jacob showed that lcc -ansic is conforming in this regard, and only lcc
without -ansic provides (f)ggets in <stdio.h>. The complaint about a
missing prototype is not an error (and a useful warning), and the
redefinition error is only given when -ansic is not included in the
compiler options.

 

[Flash Gordon]

Keith Thompson wrote, On 21/05/08 18:38:

If "lcc -ansic" is not intended to be a conforming C implementation,
then it's perfectly ok (and I suggest that discussion of it should be
limited to comp.compilers.lcc).

If it is intended to be a conforming C implementation, then this is a
bug, and you just might want to consider fixing it.

Well, it is only a warning, and the standard allows the implementation
to generate warnings for valid code. A better test would be defining
ggets in one translation unit and calling it from another then verify
that your version is the one called.

Also redefine fggets and make sure the correct routine is called for that.

Having said that, I personally would consider it better if it did not
produce the warning.

Since I'm not an lcc-win user, I'm mostly indifferent to whether you
consider this a bug or not. But *if* you want to claim that lcc-win
(mostly) conforms to the C99 standard, my advice is to go through the
standard headers and make sure that any identifiers outside the
implementation name space that aren't specified in the standard do not
appear in conforming mode.

<snip>

I agree that this would be better than producing warnings for them even
if it otherwise does the right thing.

 

[Keith Thompson]

jacob showed that lcc -ansic is conforming in this regard, and only lcc
without -ansic provides (f)ggets in <stdio.h>. The complaint about a
missing prototype is not an error (and a useful warning), and the
redefinition error is only given when -ansic is not included in the
compiler options.

You're absolutely right, and I was absolutely wrong. I didn't see the
second "lcc tggets.c" command, and assumed that both the warning and
the error message were from the same invocation of "lcc -ansic
tggets.c". I also didn't notice my own error of omitting the type on
the parameter declaration; I wrote "int ggets(x)" rather than "int
ggets(int x)", something that I would have caught if I had compiled in
conforming mode (ironic, given what I was complaining about).

jacob, please accept my sincere (and embarrassed) apologies. And the
same to anyone else whom I may have inadvertently misled.

 

[Keith Thompson]

jacob navia <[email protected]> writes:

[response to my earlier question snipped]

If "lcc -ansic" is not intended to be a conforming C implementation,
then it's perfectly ok (and I suggest that discussion of it should be
limited to comp.compilers.lcc).

If it is intended to be a conforming C implementation, then this is a
bug, and you just might want to consider fixing it.

[snip]

Please disregard my above-quoted followup. I was quite spectacularly
wrong. See my followup to Harald for details.

 

[Flash Gordon]

Harald van Dijk wrote, On 21/05/08 19:02:

jacob showed that lcc -ansic is conforming in this regard, and only lcc
without -ansic provides (f)ggets in <stdio.h>. The complaint about a
missing prototype is not an error (and a useful warning), and the
redefinition error is only given when -ansic is not included in the
compiler options.

Oops, I missread Jacob's post as well. Sorry Jacob.

 

[Keith Thompson]

Keith Thompson wrote, On 21/05/08 18:38:

Well, it is only a warning, and the standard allows the implementation
to generate warnings for valid code. A better test would be defining
ggets in one translation unit and calling it from another then verify
that your version is the one called.

Also redefine fggets and make sure the correct routine is called for that.

Having said that, I personally would consider it better if it did not
produce the warning.

Actually, I think it's a perfectly good warning, and it has nothing to
do with the declaration of ggets() in <stdio.h>. I wrote
int ggets(x)
when I meant to write
int ggets(int x)
The former is still legal, but I *want* my compiler to warn me about it.

[snip]

 

[Keith Thompson]

No, you want: int ggets(char **line); So you can use:

while (0 == ggets(&lineptr)) {
/* process it, maybe free(lineptr) */
}

to handle the whole file, barring io errors or memory exhaustion.
It is simplest to use #include "ggets.h".

I'm afraid you've completely missed the point.

My program was intended to declare its own function with the name
"ggets", completely unrelated to your function of the same name. The
point is that the identifier "ggets" is not reserved by the language,
and cannot legally be reserved by an implementation, and so any
program is allowed to use that identifier (not your function with that
name, just the identifier) for its own purposes.

I'm pleased to see that lcc-win with the "-ansic" option gets this
right (and, as a bonus, issues a warning about my bone-headed mistake
of forgetting the parameter type).

IMHO it would have been better for lcc-win to declare fggets() and
ggets() in a separate implementation-defined header rather than in
<stdio.h> (Chuck, you even provide the ggets.h header), but the way
lcc-win does it is in accordance with the standard.

 

[Eligiusz Narutowicz]

Okay. In which case I think jacob must distribute a copy of ggets
license along with his own license in the lcc-win distribution.

Strangely though I can't seem to find ggets anywhere in my lcc-win
installation. Perhaps jacob has modified the source file name?

Are you sure you do not think you are the group moderator?

 

[lovecreatesbea...]

jacob navia wrote: [...]

Chuck falconer 'ggets' is distributed with lcc-win.

I suppose I'm overlooking something but won't there be license
incompatibility between Chuck's ggets and your lcc-win?

There is no license.  According to the readme.txt file from ggets.zip:

    I have put this in the public domain.  Use as you will. I would
    appreciate attribution when used.

I'm confused. Are you and Mr. Chuck the same person?

 

[Keith Thompson]

Are you sure you do not think you are the group moderator?

In a very real sense, he *is* the group moderator. So am I.
So are you. So is everyone who participates here. It's how we
manage to have an anarchy without total chaos.

But I don't see how your question follows from what santosh wrote.
He wasn't trying to enforce any topicality rules, he was merely
participating in a technical discussion (which had veered a bit
off-topic but not fatally so IMHO). (And as for the point he was
asking about, it turns out that ggets is public domain, not GPL,
so no license exists; santosh just wasn't aware of that.)

 

[Keith Thompson]

jacob navia wrote: [...]
Chuck falconer 'ggets' is distributed with lcc-win.

I suppose I'm overlooking something but won't there be license
incompatibility between Chuck's ggets and your lcc-win?

There is no license.  According to the readme.txt file from ggets.zip:

    I have put this in the public domain.  Use as you will. I would
    appreciate attribution when used.

I'm confused. Are you and Mr. Chuck the same person?

No. As I indicated, I was quoting the readme.txt file from Chuck's
ggets.zip. (The indentation was meant to indicate quotation.)

 

[domestos!]

CBFalconer said:

I put [ggets] in the public domain. The idea was to encourage
it to spread.

Given ggets's problems, encouraging its spread might not be a
good idea.

I don't know what's wrong with you.

I am curious myself. Does 'ggets' do anything not covered in its spec?

When originally published you were enthusiastic, and had your own
version.

On the other hand, I haven't seen a review of RH's 'fgetine' from you.
I guess many readers of clc would be very interested.

I even put a reference to your version on my display of the download
directory. Over the past year you have become sour and totally
unreasonable. You never mention your family or kids any more.

On another hand, family and kids are not topical on clc.

 

[ymuntyan]

CBFalconer said:
<snip>
I put [ggets] in the public domain.  The idea was to encourage
it to spread.
Given ggets's problems, encouraging its spread might not be a
good idea.

I don't know what's wrong with you.

I am curious myself.  Does 'ggets' do anything not covered in its spec?

Yes, item 0:

0) It shall follow the best programming practices.

What the best programming practices are should be
obvious by now. Here are some quotes from the BPP Book:

623) ggets() should have the following interface:
... /* this part is omitted in my copy of the book for some reason,
* only some general recommendations are provided */
876) Freeing allocated buffer is hard.

Yevgen