Author Topic: acedRetStr  (Read 3010 times)

0 Members and 1 Guest are viewing this topic.

pkohut

  • Guest
acedRetStr
« on: June 30, 2010, 06:18:06 AM »
ARX docs state -
Quote
The acedRetStr() function passes the entire string, not its address. If s is too long, it is truncated. The maximum allowable length is 503 characters (with the 504th character reserved for the null character, EOS).

though I'm not seeing this behavior in 2008 and don't know what the limit is. For testing I've returned a 119717 (arbitrary, just what was generated) byte unicode string and it prints perfectly in Autolisp. Anyone have insight about this, like what version of AC this was changed in? Thanks.

Step 1 define an ADS callable function, have it make a big string and return it, something like this (not tested)
Code: [Select]
int Test(resbuf * pRb)
{
  ACHAR szBuf[10];
  AcString str;
  for(int i = 0; i < 1000; ++i) {
    str += itot(i, szBuf, 10) + _ACRX_T("\n");
  }
  acedRetStr(str);
  return RTNORM;
}

in Autolisp call the ads function
Code: [Select]
(setq sVal (Test))(strlen sVal)

It's Alive!

  • BricsCAD
  • Needs a day job
  • Posts: 6963
  • AKA Daniel
Re: acedRetStr
« Reply #1 on: June 30, 2010, 06:48:39 AM »
I get this in 06

Code: [Select]
static int ads_ntest(void)
 {
   const int slen = 2048;
   char *x = (char *)malloc(slen*sizeof(char));
   memset(x,'z',(slen-1)*sizeof(char));
   acedRetStr(x);
   free(x);
   return (RSRSLT) ;
 }


pkohut

  • Guest
Re: acedRetStr
« Reply #2 on: June 30, 2010, 07:05:25 AM »
I get this in 06

Ok, thanks. At least it's better than 503  :-)

It's Alive!

  • BricsCAD
  • Needs a day job
  • Posts: 6963
  • AKA Daniel
Re: acedRetStr
« Reply #3 on: June 30, 2010, 07:24:28 AM »
its the same in 2002, I would bet the change was made ADS -> ARX

pkohut

  • Guest
Re: acedRetStr
« Reply #4 on: June 30, 2010, 08:02:32 AM »
its the same in 2002, I would bet the change was made ADS -> ARX

Looks like it grew to 0x66666667 (1,717,986,919) in the 32bit '08 version ('07 ??).

It's Alive!

  • BricsCAD
  • Needs a day job
  • Posts: 6963
  • AKA Daniel
Re: acedRetStr
« Reply #5 on: June 30, 2010, 08:05:34 AM »
So it looks like your good for Acad 2000 - 2011, I Haven't test Bricscad  :wink:

It's Alive!

  • BricsCAD
  • Needs a day job
  • Posts: 6963
  • AKA Daniel
Re: acedRetStr
« Reply #6 on: June 30, 2010, 08:11:19 AM »
2002

pkohut

  • Guest
Re: acedRetStr
« Reply #7 on: June 30, 2010, 08:24:45 AM »
So it looks like your good for Acad 2000 - 2011, I Haven't test Bricscad  :wink:

I'm not a hundred percent sure on that value, just walked the disassembly of acedRetStr in debug and there is a "mov eax, 66666667h". Looking at it closing and I'm still not sure how big it is, or if that is the correct spot.


Code: [Select]
mov eax, 66666667h
imul ebx
sar edx, 2
mov eax, edx
shr eax, 1fh
cmp eax, 1fh
« Last Edit: June 30, 2010, 09:35:52 AM by pkohut »

pkohut

  • Guest
Re: acedRetStr
« Reply #8 on: June 30, 2010, 09:53:47 AM »
Somewhere between 267,500,000 and 268,000,000 is the limit on the current machine. Probably is as much as the OS can allocate memory for.

Daniel, FYI, the code you posted is no good for unicode. When array is copied over to the ACHAR then what autolisp reports is a huge value which has to do with how unicode is encoded.  That I understood and caught right off, but I changed the array fill to
Code: [Select]
_tcsnset(x, _ACRX_T('z'), slen -1);
x[slen - 1] = _ACRX_T('\0')
l
and spent the next 15 minutes trying to figure out the bug. Again, it's the unicode encoding rules at play, exact same bug as before, just more subtle. Anyways, change it to this to eliminate the bug.

Code: [Select]
std::fill(x, x + slen - 2, _T('z'));
x[slen - 1] = _ACRX_T('\0'); // edit: ack, did it again. Don't do this. Use the proper accessors, you get the idea.
« Last Edit: June 30, 2010, 09:59:01 AM by pkohut »