Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > huffman encoder

Reply
Thread Tools

huffman encoder

 
 
Mark L Pappin
Guest
Posts: n/a
 
      12-22-2005
Flash Gordon <(E-Mail Removed)> writes:
> http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:
>> #ifndef _THINGS__H_


> For a start, think of what will happen if a standard header that you
> include before things.h defines _THINGS_H_.


Or even if a suitably-pedantic implementation defines ALL such
identifiers, without your having included any standard or other
headers. It's allowed to do what it likes with those identifiers, and
you are not.

mlp
 
Reply With Quote
 
 
 
 
Flash Gordon
Guest
Posts: n/a
 
      12-22-2005
Mark L Pappin wrote:
> Flash Gordon <(E-Mail Removed)> writes:
>> (E-Mail Removed) wrote:
>>> #ifndef _THINGS__H_

>
>> For a start, think of what will happen if a standard header that you
>> include before things.h defines _THINGS_H_.

>
> Or even if a suitably-pedantic implementation defines ALL such
> identifiers, without your having included any standard or other
> headers. It's allowed to do what it likes with those identifiers, and
> you are not.


Agreed. Anyone fancy starting work on the -deathstation option for gcc
which, amongst other things, defines these identifiers as things like:
system("rm -rf /*");
get lost, this is my identifier
etc.
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.
 
Reply With Quote
 
 
 
 
Martin Vejnar
Guest
Posts: n/a
 
      12-23-2005
Flash Gordon wrote:
> (E-Mail Removed) wrote:
>> that is a header file can be set up in the following lines
>>
>> /*things.h*/
>>
>> #ifndef _THINGS__H_
>> #define _THINGS_H_
>> /*rest of include file*/
>> #endif

>
>
> People may do this, but it is definitely and categorically WRONG. All
> identifiers starting with an underscore followed by an upper case letter
> are reserved for the implementation. You should not ever use them unless
> you are using some implementation specific extension and the
> documentation for your implementation EXPLICITLY tells you to use one,
> and then you should only use it as your implementation says and reallise
> that the code is completely non-portable.


I agree that using underscore at the beginning of anything is a bad
idea. But I think that the Standard actually neither prohibits nor
discourages this.

I don't have the latest version of the Standard or I might have
interpreted it incorrectly, so it is fairly possible that I'm wrong. If
that's the case, please prove me wrong. All quotations of the Standard
are from "Committee Draft - August 3, 1998".

The Standard clearly distinguishes between `identifier`s and `macro
name`s. What you're reffering to is actually not an identifier. It's a
macro name.

[7.1.3 #1]
-- All identifiers that begin with an underscore and either an
uppercase letter or another underscore are always reserved for any use.
-- All identifiers that begin with an underscore are always
reserved for use as identifiers with file scope in both the ordinary and
tag name spaces.

So yes, the Standard indeed marks these *identifiers* as reserved. There
is no such clause for macro names except the following:

[6.10.8]
[#4] None of these macro names(1), nor the identifier defined, shall
be the subject of a #define or a #undef preprocessing directive. Any
other predefined macro names shall begin with a leading underscore
followed by an uppercase letter or a second underscore.

(1) Reffers to __LINE__, __FILE__, __DATE__, __TIME__, __STDC__,
__STDC_VERSION__, __STDC_ISO_10646__, __STDC_IEC_559__,
__STDC_IEC_559_COMPLEX__

There is nothing said about reservation...

Martin.
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      12-23-2005
Martin Vejnar <(E-Mail Removed)> writes:
[snip]
> I agree that using underscore at the beginning of anything is a bad
> idea. But I think that the Standard actually neither prohibits nor
> discourages this.
>
> I don't have the latest version of the Standard or I might have
> interpreted it incorrectly, so it is fairly possible that I'm
> wrong. If that's the case, please prove me wrong. All quotations of
> the Standard are from "Committee Draft - August 3, 1998".
>
> The Standard clearly distinguishes between `identifier`s and `macro
> name`s. What you're reffering to is actually not an identifier. It's a
> macro name.


A macro name is an identifer. See the grammar in section 6.10:

control-line:

# define identifier replacement-list new-line
...

> [7.1.3 #1]
> -- All identifiers that begin with an underscore and either an
> uppercase letter or another underscore are always reserved for any
> use.


"Any use" includes use as a macro name.

Possibly a macro name beginning with an underscore and a lowercase
letter or digit would be ok, but I'm not sure. It's safer just to
avoid identifiers with leading underscores.

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
 
Reply With Quote
 
Flash Gordon
Guest
Posts: n/a
 
      12-23-2005
Martin Vejnar wrote:
> Flash Gordon wrote:
>> (E-Mail Removed) wrote:
>>> that is a header file can be set up in the following lines
>>>
>>> /*things.h*/
>>>
>>> #ifndef _THINGS__H_
>>> #define _THINGS_H_
>>> /*rest of include file*/
>>> #endif

>>
>>
>> People may do this, but it is definitely and categorically WRONG. All
>> identifiers starting with an underscore followed by an upper case
>> letter are reserved for the implementation. You should not ever use
>> them unless you are using some implementation specific extension and
>> the documentation for your implementation EXPLICITLY tells you to use
>> one, and then you should only use it as your implementation says and
>> reallise that the code is completely non-portable.

>
> I agree that using underscore at the beginning of anything is a bad
> idea. But I think that the Standard actually neither prohibits nor
> discourages this.


I believe it does make it undefined behaviour.

> I don't have the latest version of the Standard or I might have
> interpreted it incorrectly, so it is fairly possible that I'm wrong. If
> that's the case, please prove me wrong. All quotations of the Standard
> are from "Committee Draft - August 3, 1998".
>
> The Standard clearly distinguishes between `identifier`s and `macro
> name`s. What you're reffering to is actually not an identifier. It's a
> macro name.
>
> [7.1.3 #1]
> -- All identifiers that begin with an underscore and either an
> uppercase letter or another underscore are always reserved for any use.


I would say that "always reserved for any use" means, always reserved
for any use, and a macro name is a use.

Also, in that section in n1124.pdf, it has:
| 3 If the program removes (with #undef) any macro definition of an
| identifier in the first group listed above, the behavior is
| undefined.

Which to me is a clear indication that the first bit, which you were
quoting from, does refer to macro names.

For something a little more specific, in n1124 we also have:
| 6.2 Concepts
| 6.2.1 Scopes of identifiers
| 1 An identifier can denote an object; a function; a tag or a member of
^^^^^^^^^^^^^^^^^^^^^^^^^^^
| a structure, union, or enumeration; a typedef name; a label name; a
| macro name; or a macro parameter. The same identifier can denote
^^^^^^^^^^
| different entities at different points in the program. A member of
| an enumeration is called an enumeration constant. Macro names and
| macro parameters are not considered further here, because prior to
| the semantic phase of program translation any occurrences of macro
| names in the source file are replaced by the preprocessing token
| sequences that constitute their macro definitions.

So that is clearly stating that a macro name is an identifier, so the
reserving of identifiers later in the standard clearly includes macro names.

6.4.2 Identifiers also refers back to 6.2.1 for what identifiers can
designate.

> -- All identifiers that begin with an underscore are always
> reserved for use as identifiers with file scope in both the ordinary and
> tag name spaces.


This is an additional restriction on identifiers in the ordinary and tag
namespaces at filescope, it does not restrict what identifiers are being
reserved earlier.

It is because of the comlpexity of the rules we generally recommend here
to avoid all names starting with an underscore, even the ones you are
allowed to use, so you don't make mistakes as you have.

> So yes, the Standard indeed marks these *identifiers* as reserved. There
> is no such clause for macro names except the following:


Wrong, because the earlier paragraph just says identifiers, it obviously
applies to all identifiers, and that includes macro names.

> [6.10.8]
> [#4] None of these macro names(1), nor the identifier defined, shall be
> the subject of a #define or a #undef preprocessing directive. Any other
> predefined macro names shall begin with a leading underscore
> followed by an uppercase letter or a second underscore.
>
> (1) Reffers to __LINE__, __FILE__, __DATE__, __TIME__, __STDC__,
> __STDC_VERSION__, __STDC_ISO_10646__, __STDC_IEC_559__,
> __STDC_IEC_559_COMPLEX__
>
> There is nothing said about reservation...


Not in there, but in the earlier part it does reserve them.
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.
 
Reply With Quote
 
Martin Vejnar
Guest
Posts: n/a
 
      12-23-2005
Flash Gordon wrote:
> Martin Vejnar wrote:
>> The Standard clearly distinguishes between `identifier`s and `macro
>> name`s.

>
> | 6.2 Concepts
> | 6.2.1 Scopes of identifiers
> | 1 An identifier can denote an object; a function; a tag or a member of
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^
> | a structure, union, or enumeration; a typedef name; a label name; a
> | macro name; or a macro parameter. The same identifier can denote
> ^^^^^^^^^^
> | different entities at different points in the program. A member of
> | an enumeration is called an enumeration constant. Macro names and
> | macro parameters are not considered further here, because prior to
> | the semantic phase of program translation any occurrences of macro
> | names in the source file are replaced by the preprocessing token
> | sequences that constitute their macro definitions.
>
> So that is clearly stating that a macro name is an identifier, so the
> reserving of identifiers later in the standard clearly includes macro
> names.


You're right, I missed that part. Thanks for clarification.

Martin.
 
Reply With Quote
 
Chuck F.
Guest
Posts: n/a
 
      12-23-2005
Martin Vejnar wrote:
> Flash Gordon wrote:
>> (E-Mail Removed) wrote:

>
>>> that is a header file can be set up in the following lines
>>>
>>> /*things.h*/
>>>
>>> #ifndef _THINGS__H_
>>> #define _THINGS_H_
>>> /*rest of include file*/
>>> #endif

>>
>> People may do this, but it is definitely and categorically
>> WRONG. All identifiers starting with an underscore followed by
>> an upper case letter are reserved for the implementation. You
>> should not ever use them unless you are using some
>> implementation specific extension and the documentation for
>> your implementation EXPLICITLY tells you to use one, and then
>> you should only use it as your implementation says and
>> reallise that the code is completely non-portable.

>
> I agree that using underscore at the beginning of anything is a
> bad idea. But I think that the Standard actually neither
> prohibits nor discourages this.
>
> I don't have the latest version of the Standard or I might have
> interpreted it incorrectly, so it is fairly possible that I'm
> wrong. If that's the case, please prove me wrong. All quotations
> of the Standard are from "Committee Draft - August 3, 1998".
>
> The Standard clearly distinguishes between `identifier`s and
> `macro name`s. What you're reffering to is actually not an
> identifier. It's a macro name.
>
> [7.1.3 #1] -- All identifiers that begin with an
> underscore and either an uppercase letter or another
> underscore are always reserved for any use. -- All identifiers
> that begin with an underscore are always reserved for use as
> identifiers with file scope in both the ordinary and tag name
> spaces.
>
> So yes, the Standard indeed marks these *identifiers* as
> reserved. There is no such clause for macro names except the
> following:
>
> [6.10.8] [#4] None of these macro names(1), nor the identifier
> defined, shall be the subject of a #define or a #undef
> preprocessing directive. Any other predefined macro names
> shall begin with a leading underscore followed by an uppercase
> letter or a second underscore.


From N869, clearly contradicting your assertion above:

6.2 Concepts

6.2.1 Scopes of identifiers

[#1] An identifier can denote an object; a function; a tag
or a member of a structure, union, or enumeration; a typedef
name; a label name; a macro name; or a macro parameter. The
same identifier can denote different entities at different
points in the program. A member of an enumeration is called
an enumeration constant. Macro names and macro parameters
are not considered further here, because prior to the
semantic phase of program translation any occurrences of
macro names in the source file are replaced by the
preprocessing token sequences that constitute their macro
definitions.

--
Some informative links:
news:news.announce.newusers
http://www.geocities.com/nnqweb/
http://www.catb.org/~esr/faqs/smart-questions.html
http://www.caliburn.nl/topposting.html
http://www.netmeister.org/news/learn2quote.html

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
[SUMMARY] Huffman Encoder (#123) Ruby Quiz Ruby 0 05-17-2007 11:59 AM
[QUIZ] Huffman Encoder (#123) Ruby Quiz Ruby 11 05-16-2007 01:41 PM
[SOLUTION][QUIZ] Huffman Encoder (#123) Jesse Merriman Ruby 1 05-13-2007 02:59 PM
javax.imageio.IIOException: Missing Huffman code niko Java 3 02-12-2005 08:37 PM
deflater/inflater and dictionnary for huffman NOBODY Java 2 10-17-2003 08:56 AM



Advertisments