Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #65805 > unrolled thread

Character display

Back to article view | Back to comp.lang.c

Contents

  Character display David Kleinecke <dkleinecke@gmail.com> - 2015-07-17 12:51 -0700
    Re: Character display James Kuyper <jameskuyper@verizon.net> - 2015-07-17 16:20 -0400
      Re: Character display David Kleinecke <dkleinecke@gmail.com> - 2015-07-17 18:57 -0700
        Re: Character display James Kuyper <jameskuyper@verizon.net> - 2015-07-17 23:22 -0400
        Re: Character display Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-18 10:18 -0700
    Re: Character display Keith Thompson <kst-u@mib.org> - 2015-07-17 13:44 -0700
      Re: Character display David Kleinecke <dkleinecke@gmail.com> - 2015-07-17 19:06 -0700
        Re: Character display Keith Thompson <kst-u@mib.org> - 2015-07-17 21:33 -0700
        Re: Character display Geoff <geoff@invalid.invalid> - 2015-07-18 00:33 -0700
          Re: Character display Geoff <geoff@invalid.invalid> - 2015-07-18 10:09 -0700
          Re: Character display James Kuyper <jameskuyper@verizon.net> - 2015-07-18 13:45 -0400
          Re: Character display David Kleinecke <dkleinecke@gmail.com> - 2015-07-18 18:51 -0700
            Re: Character display Keith Thompson <kst-u@mib.org> - 2015-07-18 21:08 -0700
              Re: Character display Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-19 00:33 -0700
                Re: Character display Robert Wessel <robertwessel2@yahoo.com> - 2015-07-19 17:03 -0500

#65805 — Character display

I have been thinking about the ideal way to handle text data in C. The 
point of departure is my disapproval of section 5.2.2 of the C90 
Standard (repeated in all later Standards). I am not arguing for
changes in C (outside of 5.2.2) but rather how to accommodate what 
I feel is ideal in Standard Freestanding C90.

It is possible to think of a digital text not as an array of 
characters but rather as an array of indices of glyphs (that would be 
used to display the text). This idea can be generalized to an array of 
actions - drawing a glyph, pronouncing a sound or even sounding a 
musical chord. Under such an assumption most of stdio is a special 
case of what might be done rather than anything a standard should
concern itself with (but of course, by declaring my interest to be 
free-standing I need not worry about stdio).

But this, essentially, leaves character constants and string literals
meaningless. If I assume there is a map from what legally can appear 
between two single quotes to an index (as there obviously is in the 
standard case) then I can say the value of '...' is the index of 
source code "word" between the quotes. But I don't want to give 
these "words" identifier status. So I assume there is a global array 
somewhere that contains this map as a set of pairs. (In standard C 
this map is simplified to an array because the indices are compact - 
but the general case can make no such assumption.)   

Then "..." means a sequence of "words" that might appear as character 
constants. I would separate these words by the same rule the pre-
processor uses - the longest possible word. (This is almost automatic 
in Standard C because a "word" usually is a character but escape-
sequences are easily handled.)  I assume the final "word" remains 
the null character.

In many cases I will need no more than 8-bits worth of indices but 
all that I assume is that all indices are the same size. That gives 
internal text a clear shape - a sequence of non-null indices 
terminating in the null index. Then I must supply functions 
"int display_a (test* t) {...}" etc. for different kinds of displays 
I may want to do. I will, of course, also need at least one input 
program.  

[toc] | [next] | [standalone]

#65808

On 07/17/2015 03:51 PM, David Kleinecke wrote:
> I have been thinking about the ideal way to handle text data in C. The 
> point of departure is my disapproval of section 5.2.2 of the C90 
> Standard (repeated in all later Standards). I am not arguing for
> changes in C (outside of 5.2.2) but rather how to accommodate what 
> I feel is ideal in Standard Freestanding C90.

Then you're facing a rather severe fundamental conceptual problem.
Freestanding C (all versions) has no way of displaying characters. The
only thing that 5.2.2 says which is meaningful in that context is
5.2.2p3: "Each of these escape sequences shall produce a unique
implementation-defined value which can be stored in a single char
object. The external representations in a text file need not be
identical to the internal representations, and are outside the scope of
this International Standard."

[toc] | [prev] | [next] | [standalone]

#65822

On Friday, July 17, 2015 at 1:20:27 PM UTC-7, James Kuyper wrote:
> On 07/17/2015 03:51 PM, David Kleinecke wrote:
> > I have been thinking about the ideal way to handle text data in C. The 
> > point of departure is my disapproval of section 5.2.2 of the C90 
> > Standard (repeated in all later Standards). I am not arguing for
> > changes in C (outside of 5.2.2) but rather how to accommodate what 
> > I feel is ideal in Standard Freestanding C90.
> 
> Then you're facing a rather severe fundamental conceptual problem.
> Freestanding C (all versions) has no way of displaying characters. The
> only thing that 5.2.2 says which is meaningful in that context is
> 5.2.2p3: "Each of these escape sequences shall produce a unique
> implementation-defined value which can be stored in a single char
> object. The external representations in a text file need not be
> identical to the internal representations, and are outside the scope of
> this International Standard."

Did you read my last paragraph? The answer is there.

[toc] | [prev] | [next] | [standalone]

#65827

On 07/17/2015 09:57 PM, David Kleinecke wrote:
> On Friday, July 17, 2015 at 1:20:27 PM UTC-7, James Kuyper wrote:
>> On 07/17/2015 03:51 PM, David Kleinecke wrote:
>>> I have been thinking about the ideal way to handle text data in C. The 
>>> point of departure is my disapproval of section 5.2.2 of the C90 
>>> Standard (repeated in all later Standards). I am not arguing for
>>> changes in C (outside of 5.2.2) but rather how to accommodate what 
>>> I feel is ideal in Standard Freestanding C90.
>>
>> Then you're facing a rather severe fundamental conceptual problem.
>> Freestanding C (all versions) has no way of displaying characters. The
>> only thing that 5.2.2 says which is meaningful in that context is
>> 5.2.2p3: "Each of these escape sequences shall produce a unique
>> implementation-defined value which can be stored in a single char
>> object. The external representations in a text file need not be
>> identical to the internal representations, and are outside the scope of
>> this International Standard."
> 
> Did you read my last paragraph? The answer is there.

Frankly, I consider your proposed replacement for 5.2.2
incomprehensible. I don't even understand it well enough to figure out
what it is I disagree with.  However, even if the committee disagrees
with me about that, your display_a() is not a solution the committee is
likely to accept for freestanding C. The reason why freestanding
implementations don't have to provide a way to display characters is
because the rules for freestanding implementations are targeted at
platforms where there may be no way to display characters.

If the ability to display characters is important for your concept of C
(and if you care about whether or not your concept has any influence on
development of the C standard), then you'd be better off deciding what
it is you don't like about hosted C, and propose either changes to the
rules for hosted C, or new rules for a third category intermediate
between the two. Note: that second option isn't likely to be acceptable
- the committee is trying (unsuccessfully, in my opinion, based upon
C2011) to avoid creating an increasing variety of different types of C.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#65858

On Saturday, July 18, 2015 at 2:57:24 AM UTC+1, David Kleinecke wrote:
> 
> Did you read my last paragraph? The answer is there.
>
You're right.
Text in C is just a convention for representing an array of indices
into some table. That convention is to reserve index zero for the
sentinel, which shall be the highest in memory.

Strings are special because C source is itself text, so it makes
sense to have a fairly light special syntax for entering them
directly. That's broken down now because of internationalisation,
I can't enter non-Latin glyphs at my keyboard, and even if I
could, it would be pointless because I can't read them anyway.
  

[toc] | [prev] | [next] | [standalone]

#65810

David Kleinecke <dkleinecke@gmail.com> writes:
> I have been thinking about the ideal way to handle text data in C. The 
> point of departure is my disapproval of section 5.2.2 of the C90 
> Standard (repeated in all later Standards). I am not arguing for
> changes in C (outside of 5.2.2) but rather how to accommodate what 
> I feel is ideal in Standard Freestanding C90.

Though the standard doesn't say so explicitly (perhaps it should),
section 5.2.2, "Character display semantics", does not (necessarily)
apply to freestanding implementations.

It talks about the behavior of fputc, which is not required for
freestanding implementations.

See N1570 4p6 (or, if you insist, the second paragraph of
section 4 of C90) for the definitions of hosted and freestanding
implementations.

> It is possible to think of a digital text not as an array of 
> characters but rather as an array of indices of glyphs (that would be 
> used to display the text).

I'm not sure I understand this.  Are you saying that the value of the
character 'A', for example (which might be 65) is an index into an
array, where the value of the array element represents the glyph (the
image that's drawn when the character is displayed)?

I think that's outside the scope of what should be in the C standard.
For example, sending the code 65 to an output device might cause a
particular hammer to strike the paper, or a print ball to rotate to a
particular position.

Even if there is a mapping from character codes to glyphs, who says it's
an array?  (There are various representations for fonts; I don't know
the details.)

The character is printed.  I don't think the C standard should concern
itself with how that's done.

>                            This idea can be generalized to an array of 
> actions - drawing a glyph, pronouncing a sound or even sounding a 
> musical chord. Under such an assumption most of stdio is a special 
> case of what might be done rather than anything a standard should
> concern itself with (but of course, by declaring my interest to be 
> free-standing I need not worry about stdio).
>
> But this, essentially, leaves character constants and string literals
> meaningless.

Character constants denote numeric values.  String literals denote
arrays of integer values terminated by a 0.  The semantics of *printing*
characters is described (with IMHO appropriate vagueness) in 5.2.2.

I might argue that the semantics of the control characters are
over-specified.  For example, printing a '\f' character commonly
*doesn't* move the active position to the initial position at the start
of the next logical page.  But the standard says they are *intended* to
produce such actions, which I suppose is enough of an escape hatch.

>              If I assume there is a map from what legally can appear 
> between two single quotes to an index (as there obviously is in the 
> standard case) then I can say the value of '...' is the index of 
> source code "word" between the quotes. But I don't want to give 
> these "words" identifier status. So I assume there is a global array 
> somewhere that contains this map as a set of pairs. (In standard C 
> this map is simplified to an array because the indices are compact - 
> but the general case can make no such assumption.)   

I don't think describing characters as indices into some hypothetical
array is helpful.

> Then "..." means a sequence of "words" that might appear as character 
> constants. I would separate these words by the same rule the pre-
> processor uses - the longest possible word. (This is almost automatic 
> in Standard C because a "word" usually is a character but escape-
> sequences are easily handled.)  I assume the final "word" remains 
> the null character.
>
> In many cases I will need no more than 8-bits worth of indices but 
> all that I assume is that all indices are the same size. That gives 
> internal text a clear shape - a sequence of non-null indices 
> terminating in the null index. Then I must supply functions 
> "int display_a (test* t) {...}" etc. for different kinds of displays 
> I may want to do. I will, of course, also need at least one input 
> program.  

I'm not clear on the context in which you feel all this is needed.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#65823

On Friday, July 17, 2015 at 1:45:03 PM UTC-7, Keith Thompson wrote:
> David Kleinecke <dkleinecke@gmail.com> writes:
> > I have been thinking about the ideal way to handle text data in C. The 
> > point of departure is my disapproval of section 5.2.2 of the C90 
> > Standard (repeated in all later Standards). I am not arguing for
> > changes in C (outside of 5.2.2) but rather how to accommodate what 
> > I feel is ideal in Standard Freestanding C90.
> 
> Though the standard doesn't say so explicitly (perhaps it should),
> section 5.2.2, "Character display semantics", does not (necessarily)
> apply to freestanding implementations.
> 
> It talks about the behavior of fputc, which is not required for
> freestanding implementations.
> 
> See N1570 4p6 (or, if you insist, the second paragraph of
> section 4 of C90) for the definitions of hosted and freestanding
> implementations.
> 
> > It is possible to think of a digital text not as an array of 
> > characters but rather as an array of indices of glyphs (that would be 
> > used to display the text).
> 
> I'm not sure I understand this.  Are you saying that the value of the
> character 'A', for example (which might be 65) is an index into an
> array, where the value of the array element represents the glyph (the
> image that's drawn when the character is displayed)?
> 
> I think that's outside the scope of what should be in the C standard.
> For example, sending the code 65 to an output device might cause a
> particular hammer to strike the paper, or a print ball to rotate to a
> particular position.
 
Of course it's outside the scope of a C standard. All the Standard
needs to supply is an interface to a suitable function.

My discussion is intended to explain why I advance certain ideas not
to suggest changes in the Standard. 

> Even if there is a mapping from character codes to glyphs, who says it's
> an array?  (There are various representations for fonts; I don't know
> the details.)
 
All that kind of nitty detail is outside the standard varous support
functions. So far as I can tell any realization except as an array
would be perverse. But who knows?

> The character is printed.  I don't think the C standard should concern
> itself with how that's done.

You do know about GUI systems?

> 
> >                            This idea can be generalized to an array of 
> > actions - drawing a glyph, pronouncing a sound or even sounding a 
> > musical chord. Under such an assumption most of stdio is a special 
> > case of what might be done rather than anything a standard should
> > concern itself with (but of course, by declaring my interest to be 
> > free-standing I need not worry about stdio).
> >
> > But this, essentially, leaves character constants and string literals
> > meaningless.
> 
> Character constants denote numeric values.  String literals denote
> arrays of integer values terminated by a 0.  The semantics of *printing*
> characters is described (with IMHO appropriate vagueness) in 5.2.2.
> 
> I might argue that the semantics of the control characters are
> over-specified.  For example, printing a '\f' character commonly
> *doesn't* move the active position to the initial position at the start
> of the next logical page.  But the standard says they are *intended* to
> produce such actions, which I suppose is enough of an escape hatch.
> 
> >              If I assume there is a map from what legally can appear 
> > between two single quotes to an index (as there obviously is in the 
> > standard case) then I can say the value of '...' is the index of 
> > source code "word" between the quotes. But I don't want to give 
> > these "words" identifier status. So I assume there is a global array 
> > somewhere that contains this map as a set of pairs. (In standard C 
> > this map is simplified to an array because the indices are compact - 
> > but the general case can make no such assumption.)   
> 
> I don't think describing characters as indices into some hypothetical
> array is helpful.
> 
> > Then "..." means a sequence of "words" that might appear as character 
> > constants. I would separate these words by the same rule the pre-
> > processor uses - the longest possible word. (This is almost automatic 
> > in Standard C because a "word" usually is a character but escape-
> > sequences are easily handled.)  I assume the final "word" remains 
> > the null character.
> >
> > In many cases I will need no more than 8-bits worth of indices but 
> > all that I assume is that all indices are the same size. That gives 
> > internal text a clear shape - a sequence of non-null indices 
> > terminating in the null index. Then I must supply functions 
> > "int display_a (test* t) {...}" etc. for different kinds of displays 
> > I may want to do. I will, of course, also need at least one input 
> > program.  
> 
> I'm not clear on the context in which you feel all this is needed.
 
Programming in modern systems.

[toc] | [prev] | [next] | [standalone]

#65829

David Kleinecke <dkleinecke@gmail.com> writes:
> On Friday, July 17, 2015 at 1:45:03 PM UTC-7, Keith Thompson wrote:
[...]
>> I'm not clear on the context in which you feel all this is needed.
>  
> Programming in modern systems.

I've just made several attempts to post a meaningful response.  I've
given up because I can't figure out just what you're trying to say, and
your history of not answering direct questions leads me to believe that
that's not going to change.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#65831

On Fri, 17 Jul 2015 19:06:26 -0700 (PDT), David Kleinecke
<dkleinecke@gmail.com> wrote:

>> The character is printed.  I don't think the C standard should concern
>> itself with how that's done.
>
>You do know about GUI systems?

By "printed" I think Keith implies displayed or otherwise presented to
the HMI.

By definition, a GUI system isn't a free-standing system. Or do you
mean a GUI system lacks usage of the stdio interface and therefore
qualifies as a kind of free-standing system? If that's the case then
the GUI system would provide an API into the HMI allowing a human to
interact with it. This API can be supported by a library implemented
in C but would be outside the standard. This API is the symbol to
glyph translator you appear to be seeking.

[toc] | [prev] | [next] | [standalone]

#65857

On 18 Jul 2015 09:08:27 GMT, ram@zedat.fu-berlin.de (Stefan Ram)
wrote:

>Geoff <geoff@invalid.invalid> writes:
>>By definition, a GUI system isn't a free-standing system. 
>
>  This only shows that you don't know the definition of
>  »freestanding implementation« in ISO C. You can't even
>  correctly write »freestanding implementation« but write
>  »free-standing system« instead!
>

And you use the words "freestanding implementation" where Kleinecke
intended to mean freestanding environment.

I mean the definition as provided in 5.1.2.1. A freestanding
environment must necessarily have some kind of physical system and
that system having an OS in support of a GUI "system" may or may not
be a freestanding environment. 

>  Or, do you really intend something different with
>  »free-standing system« than with »freestanding
>  implementation«? If so, what?
> 
When I was in school the word freestanding didn't exist, compound
words such as these were hyphenated. Old habits die hard.

I your beef with me using Kleinecke's use of the word system or with
the word system? 

In N1570 the words "freestanding implementation" are used 3 times,
"freestanding environment" is used 6 times and "GUI" is used not at
all. Which do you think the standard is most concerned about
describing?

[toc] | [prev] | [next] | [standalone]

#65860

On 07/18/2015 03:33 AM, Geoff wrote:
> On Fri, 17 Jul 2015 19:06:26 -0700 (PDT), David Kleinecke
> <dkleinecke@gmail.com> wrote:
> 
>>> The character is printed.  I don't think the C standard should concern
>>> itself with how that's done.
>>
>> You do know about GUI systems?
> 
> By "printed" I think Keith implies displayed or otherwise presented to
> the HMI.
> 
> By definition, a GUI system isn't a free-standing system.

What definition are you referring to? The standard defines "conforming
freestanding implementation" in section 4p6, and a careful comparison
with the definition of a "conforming hosted implementation" is that the
standard imposes fewer requirements on freestanding implemenations. It's
definition of a "freestanding environment" in 5.1.2.1 is also entirely
in terms of the standard imposing fewer requirements.

I'm familiar with GUIs which take over main() for themselves, leaving
users to define a function with a different name and interface as the
starting point for user code. That prevents them from qualifying as
"hosted", while allowing them to qualify as freestanding. But that's not
a necessary consequence of having a GUI.

[toc] | [prev] | [next] | [standalone]

#65879

On Saturday, July 18, 2015 at 12:33:05 AM UTC-7, Geoff wrote:
> On Fri, 17 Jul 2015 19:06:26 -0700 (PDT), David Kleinecke
> <dkleinecke@gmail.com> wrote:
> 
> >> The character is printed.  I don't think the C standard should concern
> >> itself with how that's done.
> >
> >You do know about GUI systems?
> 
> By "printed" I think Keith implies displayed or otherwise presented to
> the HMI.
> 
> By definition, a GUI system isn't a free-standing system. Or do you
> mean a GUI system lacks usage of the stdio interface and therefore
> qualifies as a kind of free-standing system? If that's the case then
> the GUI system would provide an API into the HMI allowing a human to
> interact with it. This API can be supported by a library implemented
> in C but would be outside the standard. This API is the symbol to
> glyph translator you appear to be seeking.

I can see that there is a confusion about the word free-standing. There
is an ordinary meaning - standing by itself - and there is a technical
maning - not hosted (not using the standrad library - apart from some
physical limiatation macros). I will use "unhosted" to mean what the
Standard calls "free-standing". 

But the rest of what you write is - apparoximately - exactly what I 
mean. I could write a unit (and call it stdio.h/c) implementing all
the functions in <stdio.h>. I wouldn't actually do exactly that
because I think is needed is not exactly the <stdio.h> API. I may
well do a version of that. 

If you write a GUI text editor you will find it hard to use hosted C.
Gedit, which is a text editor written in C90, if it uses the hosted 
API uses it so far from the user as to be invisible.  

[toc] | [prev] | [next] | [standalone]

#65882

David Kleinecke <dkleinecke@gmail.com> writes:
[...]
> I can see that there is a confusion about the word free-standing. There
> is an ordinary meaning - standing by itself - and there is a technical
> maning - not hosted (not using the standrad library - apart from some
> physical limiatation macros). I will use "unhosted" to mean what the
> Standard calls "free-standing". 

The standard uses the term "freestanding implementation".  Since this is
comp.lang.c, please use the terms defined by the standard, the way the
standard defines them, if you're interested in communicating.

[...]
> If you write a GUI text editor you will find it hard to use hosted C.
> Gedit, which is a text editor written in C90, if it uses the hosted 
> API uses it so far from the user as to be invisible.  

Presumably it would use functions declared in <stdio.h> to read and
write text files, in <stdlib.h> to allocate and deallocate memory, in
<string.h> for string handling, in <time.h> if it needs to know the
current time, and so forth.  Certainly it would have to use some
non-standard functions; most programs do.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#65886

On Sunday, July 19, 2015 at 5:09:02 AM UTC+1, Keith Thompson wrote:
> David Kleinecke <dkleinecke@gmail.com> writes:
> 
> Presumably it would use functions declared in <stdio.h> to read and
> write text files, in <stdlib.h> to allocate and deallocate memory, in
> <string.h> for string handling, in <time.h> if it needs to know the
> current time, and so forth.  Certainly it would have to use some
> non-standard functions; most programs do.
> 
It depends what you think a program should do. In the PC world,
most of the programs the user sees put up graphical interfaces
for h to interact with. And some things you can't do any other way,
a drawing tool for artists, for example, inherently needs graphics.

But my latest offering on Sourceforge is ImageToSVG. It converts
a bitmap image (gif, jpeg, png) to a greyscale SVG. It's all pure
ANSI C. Most of the code is, of course, to parse the various
input image formats, and I'm currently working on a TIFF reader
(a very tedious task, it's essentially a write-only file format,
they can't even be bothered to specify an endianness for some
reason - how hard is it to write fputc( (x & 0xFF00) >> 8, fp),
fputc(x & 0xFF, fp) in an enocoder rather than write fwrite(&x,
1, sizeof(x), fp)? Compare with what a nuisance it is to have to 
pass an endianness flag to every single read). 

It's tempting just to call an OS-specifc "readimage". But then the
program will break in a few years. As it is, it will run until
either stdlib or the C language is vandalised.

[toc] | [prev] | [next] | [standalone]

#65937

On Sun, 19 Jul 2015 00:33:16 -0700 (PDT), Malcolm McLean
<malcolm.mclean5@btinternet.com> wrote:

>On Sunday, July 19, 2015 at 5:09:02 AM UTC+1, Keith Thompson wrote:
>> David Kleinecke <dkleinecke@gmail.com> writes:
>> 
>> Presumably it would use functions declared in <stdio.h> to read and
>> write text files, in <stdlib.h> to allocate and deallocate memory, in
>> <string.h> for string handling, in <time.h> if it needs to know the
>> current time, and so forth.  Certainly it would have to use some
>> non-standard functions; most programs do.
>> 
>It depends what you think a program should do. In the PC world,
>most of the programs the user sees put up graphical interfaces
>for h to interact with. And some things you can't do any other way,
>a drawing tool for artists, for example, inherently needs graphics.
>
>But my latest offering on Sourceforge is ImageToSVG. It converts
>a bitmap image (gif, jpeg, png) to a greyscale SVG. It's all pure
>ANSI C. Most of the code is, of course, to parse the various
>input image formats, and I'm currently working on a TIFF reader
>(a very tedious task, it's essentially a write-only file format,
>they can't even be bothered to specify an endianness for some
>reason - how hard is it to write fputc( (x & 0xFF00) >> 8, fp),
>fputc(x & 0xFF, fp) in an enocoder rather than write fwrite(&x,
>1, sizeof(x), fp)? Compare with what a nuisance it is to have to 
>pass an endianness flag to every single read). 
>
>It's tempting just to call an OS-specifc "readimage". But then the
>program will break in a few years. As it is, it will run until
>either stdlib or the C language is vandalised.


TIFF dates from the (thankfully brief) era where a bunch of people
thought bi-endian support in external formats was a good idea.  In
retrospect made things a bit easier for output (sometimes), but harder
for input, no matter if you matched the endianess of the sender or
not.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c

csiph-web