Compiler differences between Teensy++2 and Teensy 3.x

[Headroom]

I apologize for the thread title as I really don't know what this issue has to do with!

I have the following lines of code in the updated EthernetBonjour library :

int EthernetBonjourClass::addServiceRecord(const char* name, uint16_t port,
                                           MDNSServiceProtocol_t proto)
{
   return this->addServiceRecord(name, port, proto, ""); //works for Teensy 2 (8-bit Atmel)
 //	return this->addServiceRecord(name, port, proto, NULL); //works for Teensy 3 (32-bit Arm Cortex)
}

Both "this->addServiceRecord" lines compile fine but as noted in the code only one of them works for the Teensy++2 and the other one for the Teensy 3.x. With "working" I mean actually registering a bonjour service so it shows up in the bonjour browser and such that I can ping the IP. When it does not work there is just no service registered and I cannot ping the IP.

The complete code for "addServiceRecord" looks like this:

// return values:
// 1 on success
// 0 otherwise
int EthernetBonjourClass::addServiceRecord(const char* name, uint16_t port,
                                           MDNSServiceProtocol_t proto, const char* textContent)
{
   int i, status = 0;
   MDNSServiceRecord_t* record = NULL;
      
   if (NULL != name && 0 != port) {
      for (i=0; i < NumMDNSServiceRecords; i++) {
         if (NULL == this->_serviceRecords[i]) {
            record = (MDNSServiceRecord_t*)my_malloc(sizeof(MDNSServiceRecord_t));
            if (NULL != record) {
               record->name = record->textContent = NULL;
               
               record->name = (uint8_t*)my_malloc(strlen((char*)name));
               if (NULL == record->name)
                  goto errorReturn;
               
               if (NULL != textContent) {
                  record->textContent = (uint8_t*)my_malloc(strlen((char*)textContent));
                  if (NULL == record->textContent)
                     goto errorReturn;
                  
                  strcpy((char*)record->textContent, textContent);
               }
               
               record->port = port;
               record->proto = proto;
               strcpy((char*)record->name, name);
               
               uint8_t* s = this->_findFirstDotFromRight(record->name);
               record->servName = (uint8_t*)my_malloc(strlen((char*)s) + 12);
               if (record->servName) {
                  strcpy((char*)record->servName, (const char*)s);

                  const uint8_t* srv_type = this->_postfixForProtocol(proto);
                  if (srv_type)
                     strcat((char*)record->servName, (const char*)srv_type);
               }

               this->_serviceRecords[i] = record;
                              
               status = (MDNSSuccess ==
                           this->_sendMDNSMessage(0, 0, (int)MDNSPacketTypeServiceRecord, i));
               
               break;
            }
         }
      }
   }
   
   return status;

errorReturn:
   if (NULL != record) {
      if (NULL != record->name)
         my_free(record->name);
      if (NULL != record->servName)
         my_free(record->servName);
      if (NULL != record->textContent)
         my_free(record->textContent);
      
      my_free(record);
   }
   
   return 0;
}

Naturally I would like to make this work for both boards without any #defines.

 

[MichaelMeissner]

The ARM compiler provided with the Teensy distribution is based on 4.7.2 (and Paul has said he plans to move to 4.8.x shortly, from the FSF side, 4.9.0 was just released). The AVR compiler that Arduino provides is a much older compiler based on 4.3.2, which is 4 major releases behind the Teensy compiler, and now 6 major releases behind what is released by the FSF. It would be nice if the AVR side moved to newer compilers, but they have encountered some compatibility problems in the past. I've seen some posts of people who have upgraded their compilers and there some things that needed to be changed with the new compiler. I have no insight as to whether the AVR stuff will ever move to a newer compiler base.

You would need somebody more skilled in the various C++ releases and standards to tell you if there is a common way of doing what you want.

 

[Headroom]

Hi Michael,

Thanks for confirming my suspicion. The whole reason I overhauled this library was to make it hardware independent. Of course that was mainly aimed at Ethernet Hardware rather than different processors and compilers and it would be somewhat frustrating having to put another #define in the code. Alas I can live with that if it is confined to this one area.