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

Submitted by:  John Darrington <jmd>
Submitted on:  Thu 13 Jul 2006 01:18:58 AM UTC  
 
Category:  None Item Group:  None
Status:  Wont Do Assigned to:  Ben Pfaff <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>
Project AdministratorIn charge of this item.
Wed 26 Jul 2006 11:22:20 AM UTC, comment #8: 

Oh yes.

I hadn't thought about the alignment issue.

John Darrington <jmd>
Project 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>
Project AdministratorIn charge of this item.
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>
Project 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>
Project AdministratorIn charge of this item.
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>
Project 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>
Project AdministratorIn charge of this item.
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>
Project 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>
Project AdministratorIn charge of this item.
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>
Project Administrator

 

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)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

     

     

    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.5