bugLiberty Eiffel - Bugs: bug #39799, class NULL_TERMINATED_STRING_ARRAY...

 
 

bug #39799: class NULL_TERMINATED_STRING_ARRAY does not compile

Submitted by:  Raphael Mack <ramack>
Submitted on:  Sat 17 Aug 2013 06:09:47 PM UTC  
 
Category: WrappersSeverity: 3 - Normal
Priority: 5 - NormalStatus: Fixed
Assigned to: Paolo Redaelli <Tybor>Open/Closed: Closed
Release: NoneFixed Release: None
Planned Release: adler

Add a New Comment (Rich MarkupRich Markup):
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Tue 27 Aug 2013 09:26:37 PM UTC, comment #2:

Removed STRING_ARRAY and NULL_TERMINATED_STRING_ARRAY: they were buggy and non-amendable.
Added in POINTER_HANDLING two queries that provides equivalent functionalities: strings_array_from and sized_strings_array_from

Paolo Redaelli <Tybor>
Project AdministratorIn charge of this item.
Sat 17 Aug 2013 08:56:16 PM UTC, comment #1:

I'm mostly offline since my mobile company don't allow tethering anymore with my plan.
Briefly, that class comes straight from 2007 and Ewlc. It's used only in Glib api for ini-like configuration files and other was both over complex and under implemented. In fact at that time the docs didn't said who owned those strings. Now it does and in all the usage the ownership is fully transferred to the user/Eiffel code. I'm fixing this ASAP.
I think I will simplify NULL–TERMINATED–STRING ARRAY turning it into a plain TRAVERSABLE[STRING]

At the beginning I just wanted to wrap char ** but as often libs docs aren't that clear about memory handling I felt obliged to duplicate their content, most probably causing Noth memory leaks and waste.
Now my knowledge has grown a little. I'll fix it ASAP

Paolo Redaelli <Tybor>
Project AdministratorIn charge of this item.
Sat 17 Aug 2013 06:09:47 PM UTC, original submission:

currently the class NULL_TERMINATED_STRING_ARRAY does not compile (which makes also the doc-generation fail).

I tried to take a look, but for me it was not clear how to fix this. What is the basic idea behind this class? Shall it store pointers to external C strings (in storage) AND a copied version of them in Eiffel String objects? This does not look very useful for me at the first glance: I fear that NULL_TERMINATED_STRING_ARRAYs have a short expected life time in the wrappers. I expect external (C) and internal (Eiffel) instances of the same string to diverge and so the wrapper needs to to a full conversion between the external and internal representation of the two string arrays anyhow each time it passes the language border...

But this is all speculation, Paolo could you explain the intention of the class and show a use case? - Maybe we could adjust the class comment to give this insight and fix the class to make it compile and be useful.

Raphael Mack <ramack>
Project Administrator

 

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

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by Tybor (Posted a comment)
  • -unavailable- added by ramack (Submitted the item)
  •  

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

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 3 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Thu 19 Sep 2013 08:50:51 PM UTCTyborStatusIn Progress=>Fixed
    Tue 27 Aug 2013 09:26:37 PM UTCTyborOpen/ClosedOpen=>Closed
    Sat 17 Aug 2013 08:57:05 PM UTCTyborStatusNone=>In Progress

    Back to the top


    Powered by Savane 3.1-cleanup