patchPSPP - Patches: patch #5236, Case Data type

 
 

You are not allowed to post comments on this tracker with your current authentication level.

patch #5236: Case Data type

Submitter:  John Darrington <jmd>
Submitted:  Thu 13 Jul 2006 01:18:58 AM UTC
   
 
Category:  None Item Group:  None
Status:  Wont Do Assigned to:  blp
Open/Closed:  Closed

Jump to the original submission

Thu 07 Jun 2007 05:33:08 AM UTC, comment #9: 

I've basically concluded there's nothing to do here.  Feel free to re-open if you disagree.

Ben Pfaff <blp>
Group administrator
Wed 26 Jul 2006 11:22:20 AM UTC, comment #8: 

Oh yes.

I hadn't thought about the alignment issue.

John Darrington <jmd>
Group administrator
Tue 25 Jul 2006 10:51:55 PM UTC, comment #7: 


> In fact, it might also be an idea to drop the union altogether and just have
> an opaque type which has size MAX_SHORT_STRING.


That's OK, as long as the opaque type has the same alignment requirements as the current "union value".  An array of MAX_SHORT_STRING chars, for example, would not.  In fact, I'm not sure what would be guaranteed to have the alignment, other than the current union.

Ben Pfaff <blp>
Group administrator
Wed 19 Jul 2006 10:57:42 PM UTC, comment #6: 

Renaming union value to union datum might be a good idea. 

In fact, it might also be an idea to drop the union altogether and just have  an opaque type which has size MAX_SHORT_STRING.  Any conversion to/from this data type should go through a function designed for the purpose, so I think we'd not be loosing much to do away with the float member altogether.

John Darrington <jmd>
Group administrator
Fri 14 Jul 2006 02:35:01 AM UTC, comment #5: 


> I would rather avoid "char" in the identifier. The whole point is,
> that the data are not (in general) characters. They are opaque data ( which
> happens to have a size equal to sizeof (char) ).


Well, I guess my point generalizes: if an observation is called an X, then calling the type of the bytes/characters/octets inside of it X_Y makes the connection obvious.  It could be datum_byte_t, datum_opaque_t, datum_octet_t, one of those with s/datum/value/, whatever.

Ben Pfaff <blp>
Group administrator
Fri 14 Jul 2006 02:29:14 AM UTC, comment #4: 


> Perhaps "datum" would be a better name for "value". And then we
> could call datum_t "datum_char_t".


I would rather avoid "char" in the identifier.  The whole point is, that the data are not (in general) characters.  They are opaque data ( which happens to have a size equal to sizeof (char) ).

John Darrington <jmd>
Group administrator
Fri 14 Jul 2006 02:24:41 AM UTC, comment #3: 


>I also thought that "datum" was too generic, but like you,
>couldn't think of a better name.


Perhaps "datum" would be a better name for "value".  And then we could call datum_t "datum_char_t".

Ben Pfaff <blp>
Group administrator
Thu 13 Jul 2006 06:00:35 AM UTC, comment #2: 

I also thought that "datum" was too generic, but like you, couldn't think of a better name.

When I started this patch I had datum_t defined in value.h, like you suggest.  I moved it to its own file, when things in libpspp needed to use it.

John Darrington <jmd>
Group administrator
Thu 13 Jul 2006 05:44:21 AM UTC, comment #1: 

So, I basically like the idea.  But:

  • "datum" is a bad name IMO.  It's too generic.  "value" is bad enough.  Maybe "string_data" or "char_data" or "value_byte" or "value_octet" or...  Actually I don't like any of those either.  The name should ideally indicate that it's related to what goes in a "union value" and that it's 8 bits in size and it's opaque.  Anyone got any ideas?


  • I think that its definition should be in value.h, because it's intimately related to what goes in a "union value".  But I'm willing to be persuaded otherwise--do you have an argument why it should be in a new header of its own?
Ben Pfaff <blp>
Group administrator
Thu 13 Jul 2006 01:18:58 AM UTC, original submission:  

I'm proposing this patch, as a first step to i18n of syntax files.

It doesn't actually do anything.  Its utility is, that compiler warnings about differing signedness flag code which is erroneously treating case data and strings as equivalent.

Once we get all such conversion performed in a single function, I think internationalisation will become easier.

John Darrington <jmd>
Group administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attached Files
file #10339:  data_type.patch added by jmd (24KiB - text/x-patch)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by blp (Updated the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2007-06-07 blp StatusPostponed Wont Do
        Open/ClosedOpen Closed
    2007-01-09 blp StatusReady For Test/Review Postponed
    2006-07-13 jmd Assigned tojmd blp
    2006-07-13 blp Assigned toblp jmd
    2006-07-13 jmd Attached File- Added data_type.patch, #10339

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code