Re: memory leak?

Hi Doug,

This is a non-issue on the TI C54xx family of DSPs where everything is
a 16-bit value. char, short, int are all 16 bits. sizeof char,
short, int are all equal to one. All of the FILE* related code for
this C/C++ compiler show examples that check feof(stream) and none of
them rely on EOF being returned by the function. The documentation
doesn't even mention the EOF as a return value.

I guess this is another example of a platform that doesn't pass your
"purity test". Even if you are right, what else could the compiler
writers reasonably be expected to do when coding for such a piece of
hardware? Their goal is to deliver a workable product for their
developers to author software with. In truth, there is very little of
reading from file systems going on inside the typical DSP application.

I realize that this DSP platform is off-topic for this forum, but I
threw it in here to point out that there is another platform with this
problem. Some problems require a common sense compromise in the name
of usability.

To summarize, there are some pieces of hardware which are not a good
match for the compiler standard. If adhering to the standard would be
very wasteful, it is better to compromise. If we admit that this sort
of thing is a reality then the arguement over the fine detail seems
pointless.

-GB

On Tue, 31 Jul 2007 10:56:38 -0500, "Doug Harrison [MVP]"
<dsh@xxxxxxxx> wrote:

On Tue, 31 Jul 2007 06:41:29 GMT, Dan Bloomquist <public21@xxxxxxxxxxx>
wrote:

Doug Harrison [MVP] wrote:

<snip>

As I understand it:

unsigned char tc= EOF;
unsigned int ti;
ti= tc;

As Doug says, it doesn't work, at least with MS 7.1.
And as I understand it, it should never work, no matter what, in today's
paradigm of c.

That's not what I'm talking about, and it's perfectly well-defined in every
C++ implementation, because the congruence relation that governs
signed->unsigned conversion is defined for all such integer types.

Let me illustrate what I've been talking about using fgetc as an example
(pseudocode, of course):

int fgetc(FILE* fp)
{
unsigned char x = get_the_next_byte(fp);
return (at_eof(fp)) ? EOF : x;
}

Typical usage is:

int i;
while ((i = fgetc(fp)) != EOF)
{
process(i);
}
if (ferror(fp))
{
deal with error
}

The problem when sizeof(int) == sizeof(char) is that EOF cannot be an int
value distinct from all unsigned char values. Therefore, the usual fgetc
loop is erroneous, because encountering an unsigned char value in the
stream corresponding to EOF causes it to terminate prematurely.

It should also be noted that the entire reason fgetc returns an int instead
of an unsigned char is so that it can return EOF, a value distinct from all
unsigned char values. It should be clear that making sizeof(int) ==
sizeof(char) is at odds with this, because as I've explained, unsigned char
uses all the bits that make up its object representation, and all bit
patterns of unsigned char are valid numbers. Thus, when sizeof(int) ==
sizeof(char), there are no bits left over in int to represent a
distinguishable int value EOF.
.

Relevant Pages

  • Putty key format.
    ... /* Hacked up ssh-add.c code to convert an OpenSSH key into a format ... static char *comment = NULL; ... int length; ... static unsigned char * buffer = NULL; ...
    (comp.security.ssh)
  • Re: scanf behaviour
    ... char, i have to reread the input until I get the needed pos. ... user input a number that's too large to be stored in an integer. ... static int ignoreblks ... which may be \n or EOF ...
    (comp.lang.c)
  • [EXPL] KSTAT (and Maybe Others) Bypass (Phantasmagoria)
    ... void cleanup_module{ ... char computed_address; ... int isNotOp; ... unsigned char backuped; ...
    (Securiteam)
  • Re: Is there any GENRIC MACROS in c for INTEGERS,CHARACTERS ?
    ... >> The descriptions of the ctype functions all take int values. ... >> that char is converted to int in this case and that if char is signed ... What is EOF for in this context? ... the 'space' characters and so 0 must be the result. ...
    (comp.lang.c)
  • Re: huffman encoder
    ... > to the specified stream and advances the position indicator for the ... > the error indicator for the stream is set and EOF is returned. ... the whole damn int does not go to the file, only the byte value of the int. ... flushing the, eg, so the last char is not truncated. ...
    (comp.compression)
Loading